[STREAM-1180] Adjust media handling based on alerting leader#994
[STREAM-1180] Adjust media handling based on alerting leader#994
Conversation
…istent connection requests
…ndling alerting leader media
…type when requesting headset controls
…ing used if there are no active conversations; also only disconnect idle connections
…ation, fallback to `reducedMediaHeadsets`
# Conflicts: # changelog.md
| const broadcastSpy = jest.fn(); | ||
| proxyService['sdk']._streamingConnection.messenger.broadcastMessage = broadcastSpy; | ||
| proxyService['sdk']._mediaHandling = MediaHandling.alertingLeaderMedia; | ||
| const device = { deviceId: 'device1Id', groupId: 'device1GroupId', label: 'device1Label', kind: 'audioinput' } as any; |
There was a problem hiding this comment.
Codacy has a fix for the issue: Unexpected any. Specify a different type.
| const device = { deviceId: 'device1Id', groupId: 'device1GroupId', label: 'device1Label', kind: 'audioinput' } as any; | |
| const device = { deviceId: 'device1Id', groupId: 'device1GroupId', label: 'device1Label', kind: 'audioinput' } as unknown; |
| /** These currently only affect softphone media */ | ||
| export enum MediaHandling { | ||
| /** Handle all media; headset controls use traditional orchestration */ | ||
| standardMedia = 'standard-media', |
There was a problem hiding this comment.
Should this be standard-media or legacy-media? Basically I'm asking if the alerting-leader behavior will/should become the new default when this is flipped on.
There was a problem hiding this comment.
I guess this probably a question for a PM too. I don't really want to see us manage so many different states in the future if we can avoid it.
There was a problem hiding this comment.
Fair question. The alerting leader behavior will not be the new default because it only applies to the clients we've hardcoded. However, I think it is possible that it will become the default at some point in the future. I think it's far enough away and unknown enough to not consider it legacy yet. 🙂
The basic idea is that as different clients become the alerting leader, the other clients should not be handling media (such as eager persistent connections) or headsets. But we still want them to be capable of outbound calls. However, the initial clients using alerting leader will be using their streaming-client connections as the alerting leader, so the SDK cannot simply react to alerting leader changes on its own. This PR allows clients to tell the SDK how it should handle media (and adjusts headset orchestration slightly so an alerting leader takes priority).
MERGE CHECKLIST
[STREAM-<ticket number>] - <description of changes>or[<issue number>] - <description of changes>.nexton npm.